Important functions in an Ethernet switch (such as a layer 2 or 3 switch) include parsing the incoming Ethernet frame, extracting multiple fields from the frame, and analyzing the Ethernet header and the higher level protocol header to decode the protocol type. This function is typically carried out in the Ethernet port control logic module. The extracted and derived information is then provided to the Ethernet switch engine to determine how to process the incoming frame from one of the ports of the switch.
Several conventional approaches have been used for implementing frame parsers. A first conventional approach is a hardcoded logic hardware implementation. Such an implementation is protocol specific, based on the assumption that the protocols supported are fixed and predefined. The key patterns are hardcoded or hardwired in the fixed logic circuitry. Each key pattern corresponds to a protocol supported by the switch. This frame parser approach parses through the incoming data stream from the MAC engine, one byte at a time for every clock cycle, and checks if the data bytes at predefined positions match the values defined in the supported protocols.
The first conventional approach can be optimized from a hardware implementation point of view. In particular, such an approach can perform frame parsing without any extra latency. Therefore, no extra buffer is needed, since the byte parsing and comparison can be completed within 1 clock cycle period in which a byte of a packet is received. However, this approach lacks flexibility and in-field upgradability after fabrication.
A second conventional approach is a microprocessor based firmware implementation. Each switch port has a designated microprocessor which is used to execute a frame parsing microcode. The microcode is used to define the key patterns the microprocessor should be looking for when parsing through the receiving byte stream. At the initialization stage, host CPU software is responsible for placing the microcode into a SRAM from which the microprocessor fetches the instructions.
The second conventional approach overcomes the problem of the first conventional approach (i.e., providing flexibility in the type of protocol supported and providing full programmability). However, the second conventional approach needs a dedicated microprocessor/micro-controller for executing the frame parsing microcode for each port. Implementing a dedicated microprocessor incurs a high silicon area penalty. In addition, the microprocessor runs at a much higher frequency than the system clock (to keep up with the network wire-speed) which increases power consumption.
A third conventional approach is a pure software implementation. After a packet is received and placed into memory buffers, the host CPU reads the data from the memory buffers, executes the software to extract multiple fields from the packet, and compares the fields with the defined values in the protocols the switch supports, therefore decoding the protocol types.
The third conventional approach is not practical for a layer 2 switch because of the intervention of host CPU software. The host CPU cannot start to parse the packet until the packet is received and placed in the memory buffer. As a result, the corresponding latency is not acceptable for high speed network applications.
It would be desirable to implement an efficient frame parser (i) with flexibility and low latency, (ii) without adding extra latency to the switch, and/or (iii) that may be suitable for high-speed networks in order to support wire-speed throughput.
It would also be desirable to implement an Ethernet frame parser that (i) is flexible and field ungradable, (ii) may be implemented without microprocessor or micro-controller to execute frame parsing microcode, (iii) does not need to run at a higher frequency than the system clock, (iv) may be implemented without the intervention of host CPU software, and (v) is capable of supporting existing and new protocols without hardware changes.